docs: plan refuses a blocked residency, Unity Catalog tag values as written, and readable table names in logs (forge-cli#868) - #212

Summary

Documents forge-cli #868, released in 0.30.0.

• fluid plan checks sovereignty by default (docs/cli/plan.md). It refuses what fluid validate refuses. Under strict that includes a binding outside allowedRegions, one in another jurisdiction, and one on AWS, GCP, Azure or Databricks that declares no region. In every mode it includes a region in deniedRegions. A refusal exits 1 with ERR_SOVEREIGNTY_VIOLATION and writes no plan. --check-sovereignty runs that check first, then the provider hook, and writes no plan on failure. --no-check-sovereignty skips the check with a warning and a WARNING log (sovereignty_check_skipped).
• Unity Catalog tag values as written (docs/providers/databricks.md): case, spaces and punctuation kept, fluid_regulation joined with , , a value over 256 characters refused as databricks-tag-value-too-long, and the in-place update (~) of a deployment made before 0.30.0.
• docs/advanced/error-codes.md: the 0.30.0 sovereignty_violation suggestions, and a governance label as a databricks-tag-value-too-long trigger.
• docs/upgrading.md: all three changes, the log-redaction one included, added to the ## Changes in 0.30.0 section docs(databricks): metric views, and a schema the contract stops using is destroyed (forge-cli#865, #873) #211 created. The plan change comes first, since it can stop a pipeline on any provider. The tag change is a bullet under ### Databricks.
• Pages the same change made wrong: docs/advanced/governance.md called plan's check opt-in, docs/concepts/sovereignty.md listed only plan --check-sovereignty, and the walkthrough's stage 6 said a failing plan still writes its file. The walkthrough now shows the 0.30.0 refusal.

Related CLI PR

• CLI PR: fix!: table names stay readable in logs, Unity Catalog tag values as written, plan refuses a blocked residency forge-cli#868

Areas Updated

• Getting Started
• CLI Reference
• Provider Docs
• Walkthroughs / Examples
• Contributing / Community Docs
• Other: upgrading, error codes, governance, sovereignty concepts, the docs-check allowlist

Checklist

• I previewed the change locally with npm run docs:dev or built it with npm run docs:build
• I checked links, page titles, and navigation where relevant
• Screenshots or command output are updated if needed

Notes

Observed on the release. Each behaviour was run on data-product-forge==0.30.0 from PyPI in a scratch venv, and compared with 0.29.0:

Under strict, a GCP binding outside allowedRegions is now refused by the default check before the gcp hook is asked, so plan.md says the hook's example output predates 0.30.0. The walkthrough's new output block is a real 0.30.0 run: no plan.json and no plan.html are written.

fluid generate iac on one Databricks contract gives the same 17 tag addresses on both releases, with these values:

redact_secret_text() masks catalog.schema.table on 0.29.0 and keeps it on 0.30.0, and a JWT stays masked on both. The live Free Edition run (+0 ~17 -0, then applied, values read back, fluid verify on 27 tags) is forge-cli's own, from #868 and its CHANGELOG.

An independent review pass re-ran these claims against the v0.30.0 source and both CLIs. Its should-fix findings are folded in: the missing-region case, apply's checks linked rather than named per cloud, the hook-path sentence in upgrading.md, the 0.29.0 slug keeping _, and the live-run wording.

Allowlist. The docs checks pin 0.29.0, whose plan parser has no --no-check-sovereignty. Without docs/cli/plan.md::--no-check-sovereignty under flag_oracle_ok, the flag oracle fails on plan.md's example; with it, it passes. Against 0.30.0 the oracle passes without the entry, so the pin bump should drop it.

Checks run locally on the branch rebased onto #211 (pinned 0.29.0, forge-cli's CHANGELOG through 0.30.0): check_cli_docs.py (all checks, markers included), check_providers.py, gen_contract_reference.py --check, npm run docs:build and node scripts/check-dist-links.mjs. All clean.

Not in this PR. The 0.30.0 pin bump: the markers that still call #861, #864 and #871 unreleased, and the "Not in a release yet" section of upgrading.md. Also a gap in the release-marker sweep that lets those markers pass CI. Both are tracked separately.